View VV0670P001_5125738.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 vision cpia data sheet (VV0670P001) colour processor interface asic commercial in confidence revision histor y rev chan g e revised b y date 1ori g inal document ed duncan 4/12/97 2first bod y text added peter slawek 09/02/98 3 amendments & added prelim vp section ed duncan 12/02/98 4 restructure and add dram timin g ed duncan 26/03/98 5 substantiated - more sections, text and dia g rams ed duncan 01/03/98 6 power mana g ement + compression + mech drawin g s ed duncan 03/03/98 7 add rems parallel port section ed duncan 10/04/98 8 extended cp section rem 13/04/98 9 add usb section and proof read document linda russell 02/07/98
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 2 commercial in confidence t he colour processor interface asic ( cpia ) is a di g ital video processor re q uirin g onl y a sin g le 4mbit dram and minimum of passive support components to provide a complete pc peripheral video capture s y stem. cpia accepts raw di g ital video data from visions cif format cmos sensors and is capable of transferrin g the resultin g yuv video data to a host pc over either usb or parallel port interfaces at rates up to 30 frames per second. the cpia architecture consists of three conceptuall y separate functional blocks: the video processor ( vp ) , the video compressor ( vc ) and the control processor ( cp ) . the vp controls the vvl404 sensor and processes the raw pixel data into cif or qcif yuv ima g es for compression and transfer to the host b y the vc. the cp is responsible for coordinatin g s y stem operation, respondin g to host re q uests and commands as well as performin g automatic camera exposure control and colour balance. ? interfaces to visions vv6404 colour cmos ima g e sensor ?directl y interfaces to a host pc usin g usb or parallel port interfaces ? 100% compliant with usb specification v1.0 ? 100% compliant with ieee1284 parallel port specifications ? support for windows 95/98 plu g and pla y ?ima g e capture at cif ( 352x288 ) and qcif ( 176x144 ) resolutions ?ima g e compression providin g up to 30fps cif ? automatic exposure control and colour balance ? camera flicker control for 50 hz and 60 hz mains driven li g htin g ? supports selective transfer of re q uested re g ions of interest to the host s y stem ? power mana g ement includin g watchdo g reset ? absolute minimum of support components ? device pinout desi g ned to facilitate la y out and area of support pcb cpia system block diagram general description colour processor interface asic vision cpia datasheet features cpia vp vc cp vvl404 ima g e sensor dram usb pp ( host ) pp ( pass )
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 3 colour processor interface asic commercial in confidence 1.1 representative device pinout cpia has been packa g ed in an industr y -standard 176 tqfp. the pinout has been carefull y developed to minimise the ph y sical size of the support printed circuit board b y facilitatin g placement of and electrical routin g to peripheral support components such as dram and parallel port connectors. reference should also be made to drawin g s located at the end of this data sheet for ph y sical dimensions and other, more detailed mechanical information. 132 nc 131 nc 130 rama[4] 129 rama[3] 128 reset 127 clk400h 126 norm 125 lopow 124 vss 123 vss 122 cko14 121 cki14 120 cko48 119 cki48 118 vdd 117 p_strobe 116 p_autofd 115 vss 114 p_fault 113 p_init 112 p_selectin 111 p_ack 110 p_busy 109 p_perror 108 p_select 107 h_select 106 h_perror 105 vss 104 h_busy 103 h_ack 102 vdd 101 vss 100 vss 99 vdd 98 hp_data[7] 97 vss 96 hp_data[6] 95 hp_data[5] 94 vss 93 hp_data[4] 92 vdd 91 hp_data[3] 90 nc 89 nc 176 tqfp 176 nc 175 nc 174 nc 173 vdd 172 vss 171 vss 170 vss 169 vss 168 ramd[15] 167 ramd[0] 166 ramd[14] 165 vss 164 ramd[1] 163 ramd[13] 162 ramd[2] 161 ramd[12] 160 ramd[3] 159 ramd[11] 158 vss 157 ramd[4] 156 ramd[10] 155 ramd[5] 154 vdd 153 ramd[9] 152 ramd[6] 151 vss 150 ramd[8] 149 ramd[7] 148 ramlcas 147 ramucas 146 ramwe 145 vss 144 ramras 143 rama[8] 142 rama[7] 141 rama[0] 140 vdd 139 rama[6] 138 rama[1] 137 rama[5] 136 vss 135 rama[2] 134 nc 133 nc nc 1 nc 2 nc 3 vdda 4 sclk 5 vss 6 sdata[0] 7 sdata[1] 8 sdata[2] 9 sdata[3] 10 ssda 11 sscl 12 vdda 13 vdda 14 vss 15 dc 16 dc 17 dc 18 dc 19 dc 20 dc 21 vss 22 dc 23 dc 24 dc 25 vdda 26 dc 27 dc 28 dc 29 dc 30 dc 31 vss 32 dc 33 dc 34 dc 35 dc 36 dc 37 dc 38 dc 39 dc 40 dc 41 nc 42 nc 43 nc 44 nc 45 nc 46 dc 47 dc 48 dc 49 debug 50 id_select 51 usb_bandwidth 52 rxd 53 vss 54 txd 55 spare0 56 spare1 57 spare2 58 vss 59 dc 60 dc 61 dc 62 dc 63 vss 64 dc 65 dc 66 dc 67 dc 68 vdda 69 vssu 70 dp 71 dn 72 vddu 73 vdd 74 h_strobe 75 h_autofd 76 h_fault 77 vss 78 h_init 79 h_selectin 80 hp_data[0] 81 vss 82 hp_data[1] 83 hp_data[2] 84 vss 85 nc 86 nc 87 nc 88 cpia
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 4 colour processor interface asic commercial in confidence 1.2 cpia pin description 1.2.1 device i/o pin signal type description drive video processor 5 sclk o (4) vvl6404 sensor clock (7.159mhz) 2 ma or 4ma 7 sdata[0] i (3) vvl6404 sensor data bus - 8 sdata[1] i (3) vvl6404 sensor data bus - 9 sdata[2] i (3) vvl6404 sensor data bus - 10 sdata[3] i (3) vvl6404 sensor data bus - 11 ssda i/o (2,3,6) vvl6404 sensor serial interface data 2 ma 12 sscl i/o (2,3,6) vvl6404 sensor serial interface clock 2 ma control processor 50 debug i control processor debug output select - 51 id_select i dual camera device id select - 52 usb_bandwidth i alternate usb bandwith settings - 53 rxd i control processor serial communications - 55 txd o(4,6) control processor serial communications 2 ma 56 spare0 i control processor spare (p1.1) - 57 spare1 i control processor spare (p3.4) 2 ma 58 spare2 i control processor spare (p3.5) 2 ma usb 71 dp i/o (1,5,7) usb differential output (+) - 72 dn i/o (1,5,7) usb differential output (-) - parallel port interface 75 h_strobe i (1,4,9) parallel port host strobe control - 76 h_autofd i (1,4,9) parallel port host autofeed control - 77 h_fault o (5,9) parallel port host fault status 16 ma 79 h_init i (1,4,9) parallel port host init control - 80 h_selectin i (1,4,9) parallel port host selectin control - 81 hp_data[0] i/o (1,4,5,9) parallel port host/pass data bus 16 ma 83 hp_data[1] i/o (1,4,5,9) parallel port host/pass data bus 16 ma 84 hp_data[2] i/o (1,4,5,9) parallel port host/pass data bus 16 ma 91 hp_data[3] i/o (1,4,5,9) parallel port host/pass data bus 16 ma 93 hp_data[4] i/o (1,4,5,9) parallel port host/pass data bus 16 ma 95 hp_data[5] i/o (1,4,5,9) parallel port host/pass data bus 16 ma 96 hp_data[6] i/o (1,4,5,9) parallel port host/pass data bus 16 ma 98 hp_data[7] i/o (1,4,5,9) parallel port host/pass data bus 16 ma 103 h_ack o (5,9) parallel port host ack status 16 ma 104 h_busy o (5,9) parallel port host busy status 16 ma 106 h_perror o (5,9) parallel port host perror status 16 ma 107 h_select o (5,9) parallel port host select status 16 ma 108 p_select i (1,4,9) parallel port pass-thru select status - 109 p_perror i (1,4,9) parallel port pass-thru perror status - 110 p_busy i (1,4,9) parallel port pass-thru busy status -
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 5 colour processor interface asic commercial in confidence 111 p_ack i (1,4,9) parallel port pass-thru ack status - 112 p_selectin o (5,9) parallel port pass-thru selectin control 16 ma 113 p_init o (5,9) parallel port pass-thru init control 16 ma 114 p_fault i (1,4,9) parallel port pass-thru fault status - 116 p_autofd o (1,5,9) parallel port pass-thru autofeed control 16 ma 117 p_strobe o (1,5,9) parallel port pass-thru strobe control 16 ma vc master clocks 119 cki48 i(8) 48.0mhz oscillator amplifier input pad - 120 cko48 o(7) 48.0mhz oscillator amplifier output pad 121 cki14 i 14.318mhz oscillator amplifier input pad - 122 cko14 o 14.318mhz oscillator amplifier output pad power management interface 125 lopow o(7) external device vcc control 2 ma 126 norm o(7) external device vcc control 2 ma 127 clk400h i (4) power management clock - 128 reset i (4) master reset - system memory (dram) interface 129 rama[3] o (10) dram multiplexed address 2 ma 130 rama[4] o (10) dram multiplexed address 2 ma 135 rama[2] o (10) dram multiplexed address 2 ma 137 rama[5] o (10) dram multiplexed address 2 ma 138 rama[1] o (10) dram multiplexed address 2 ma 139 rama[6] o (10) dram multiplexed address 2 ma 141 rama[0] o (10) dram multiplexed address 2 ma 142 rama[7] o (10) dram multiplexed address 2 ma 143 rama[8] o (10) dram multiplexed address 2 ma 144 ramras_n o (10) dram row address strobe 8 ma 146 ramwe_n o (10) dram data write enable 2 ma 147 ramucas_n o (10) dram upper column address strobe 8 ma 148 ramlcas_n o (10) dram lower column address strobe 8 ma 149 ramd[7] i/o (10) dram data 2 ma 150 ramd[8] i/o (10) dram data 2 ma 152 ramd[6] i/o (10) dram data 2 ma 153 ramd[9] i/o (10) dram data 2 ma 155 ramd[5] i/o (10) dram data 2 ma 156 ramd[10] i/o (10) dram data 2 ma 157 ramd[4] i/o (10) dram data 2 ma 159 ramd[11] i/o (10) dram data 2 ma 160 ramd[3] i/o (10) dram data 2 ma 161 ramd[12] i/o (10) dram data 2 ma 162 ramd[2] i/o (10) dram data 2 ma 163 ramd[13] i/o (10) dram data 2 ma 164 ramd[1] i/o (10) dram data 2 ma 166 ramd[14] i/o (10) dram data 2 ma 167 ramd[0] i/o (10) dram data 2 ma pin signal type description drive
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 6 colour processor interface asic commercial in confidence if the tar g et application re q uires that onl y one interface mode is re q uired ( e g . usb interface onl y) , please refer to the above table and notes 7, 8 and 9 to establish how unused pins should be electricall y connected on the pcb. failure to ensure such pins are correctl y connected ma y result in erroneous s y stem behaviour. notes: 1. internal pullups. 2. these pins shall g o tri-state when lopow is hi g h. 3. ttl level schmitt input. v il(max) = 0.8v, v ih (min) = 2.2v, schmitt tri gg er h y steresis=250mv ( t y p ) . input leaka g e -10 m a to +10 m a, v in : 0 to dvdd 4. output v ol(max) =0.4v @ i ol =16ma v oh(min) =2.4v @ i oh = -12ma 5. these si g nals to compl y with usb specification version 1.0 section 7. 6. open drain output. v ol(max) =0.4v @ i ol =3ma 7. this pin does not re q uire connection if cpia is used for parallel port interfacin g products onl y . 8. this pin should be tied low if cpia is used for parallel port interfacin g products onl y . 9. this pin does not re q uire connection if cpia is used for usb interfacin g products onl y . 10. these pins shall g o tri-state when norm is hi g h. where i/o pad t y pe is not explicitl y defined in the above notes assume cmos. 168 ramd[15] i/o (10) dram data 2 ma pin signal type description drive
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 7 colour processor interface asic commercial in confidence 1.2.2 device power, nc and dc pins 1.3 absolute max ratings 1.4 dc characteristics pin signal description 6, 15, 22, 32, 54, 64, 78, 82, 85, 94, 100, 101, 105, 115, 124, 136, 145, 151, 158, 165, 97 vss digital padring & logic ground. 59, 123, 169, 170, 171, 172 vss reserved signal inputs (tie low) 4, 13, 14, 26, 69 vdda digital padring & logic power for vp & cp 74, 92, 99, 102, 118, 140, 154, 173 vdd digital padring & logic power for vc 70 vssu ground for the usb 73 vddu 3.3v supply for the usb 16, 17, 18, 19, 20, 21, 23, 24, 25, 27, 28, 29 , 30, 31, 33, 34, 35,36, 37, 38, 39, 40, 41, 47, 48, 49 dc do not connect these pins 1, 2, 3, 42, 43, 44, 45, 46, 86, 87, 88, 89, 90, 131, 132, 133, 134, 174, 175, 176 nc not connected pins 60, 61, 62, 63, 65, 66, 67, 68 dc do not connect these pins description range unit ambient temperature 0 to 40 o c storage temperature -50 to 150 o c voltage on usb d+/d-, vcc3v to vss v voltage on any other i/o to vss v parameter description min max units vdd primary cpia power supply v vdda secondary cpia power supply v vddu 3.3v power supply for on-chip usb tranceiver v isuspend cpia suspend mode current ua ilowpo cpia low power modecurrent ma iactive cpia active, high power mode current ma vilu, vihu usb differential pad d+/d- vil, vih see section 1.2 v volu, vohu usb differential pad d+/d- vol, voh v iilu, iihu usb differential pad d+/d- iil, ili ma vilp, vihp parallel port pads vil, vih v volp, vohp parallel port pads vol, voh v iilp, iihp parallel port pads iil, ili ma vild, vihd dram interface pads vil, vih v vold, vohd dram interface pads vol, voh v iild, iihd dram interface pads iil, ili ma vilm, vihm power management pads vil, vih v volm, vohm power management pads vol, voh v iilm, iihm power management pads iil, ili ma
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 8 colour processor interface asic commercial in confidence 2 cpia functional description 2.1 video processor module the cpia video processor module provides cif-format 4:2:2-sampled di g ital video to the vc module at frame rates up to 30 frames per second and also interfaces directl y to the 356 x 292 pixel colour cmos ima g e sensor provided in visions vm6404 camera head module. usin g a 9-wire cable and an absolute minimum of external components, the interface incorporates: 1. a 4-wire data bus sdata[3:0] for receivin g both video data and embedded timin g references. 2. a 2-wire serial interface ssda,sscl for controllin g the camera. 3. the clock for camera module sclk. 4. 5v and 0v power lines. cpia is not re q uired to provide power directl y to the camera; camera power is derived from the s y stem power suppl y . the simplified block dia g ram shown below hi g hli g hts the ke y functional blocks within cpias vp module. cpia provides a master clock sclk to the camera module. each 8-bit pixel value g enerated b y the camera is transmitted across the 4 wire databus sdata[3:0] as a pair of se q uential 4-bit nibbles, most si g nificant nibble first. codes representin g the start and end frames and the start and end of lines are embedded within the video pixel data stream to allow the receiver to s y nchronise with the video data which the camera module is g eneratin g . the video processin g en g ine performs these basic functions on incomin g data: full colour restoration at each pixel site from ba y er-patterned input data, matrixin g / g ain on each colour channel for colour purit y , aperture correction for ima g e clarit y , g amma correction, and colour space conversion ( includin g hue and saturation control ) from rgb to ycbcr. ima g e statistic monitors g ather data re q uired b y the cp module for end-of-frame housekeepin g tasks such as exposure control and colour balance. the 2-wire camera serial interface provides complete control over how the sensor is setup and run. colour video registers ssda sscl sdata[3:0] receiver sclk clock & control pixel defect engine serial inter- face monitors correction cp control interface vc video data interface block dia g ram of cpia video processor module
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 9 colour processor interface asic commercial in confidence camera exposure and g ain values are pro g rammed via this interface. the followin g table and dia g ram illustrate the camera power up se q uence. pu0 s y stem power up pu1 sensor internal-on reset tri gg ers, the sensor enters low power mode and sdata[3:0] is set to f h . pu2 cpia internall y releases video processin g modules from reset. note - this event is under the control of the control processor, and does not occur until the host has re q uested video from the camera. pu3 cpia enables the sensor clock, sclk. pu4-pu5 at least 16 sclk clock periods after sclk has been enabled cpia sends a soft- reset command to the sensor via the serial interface. this ensures that if a sensor is present then it is in low-power mode. pu6 on detectin g 32 consecutive f h values on sdata [3:0], cpia detects the camera pu7-pu8 if present, cpia uploads the sensor defect map from camera head e 2 prom. pu13-pu4 at least 16 sclk clock periods after sclk has been enabled, cpia sends an exit low-power mode command to the sensor via the serial interface. this initiates the sensors 4 frame start se q uence. pu15-pu16 one frame of alternatin g 9 h & 6 h data on sdata[3:0] for the cpia to determine the best samplin g phase for the nibble data sdata[3:0]. pu17-pu18 4 frames after the exit low-power mode serial comms, the sensor starts to output valid video data. f h f h 5v 0v 2.8v 9 h ,6 h ,9 h ,6 h ... regulated sensor power sdata[3:0] sclk ssda sscl pu0 pu1 pu3 pu2 pu4 pu5 pu6 pu7 pu8 start of frame line for the 1st frame of valid one frame of 9 h & 6 h data. pu13 pu14 pu15 pu16 pu17 pu18 camera head interface behaviour up to and including first valid video data
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 10 colour processor interface asic commercial in confidence 2.2 video compressor module 2.2.1 power management the power mana g ement block is primaril y responsible for low-level control of s y stem power, clocks and reset se q uences to ensure full compliance with the usb specification and power savin g modes of operation. this module also includes a watchdo g reset ensurin g , for example, the s y stem alwa y s returns to a safe state if power-failure or an y other event has caused cpia to encounter an unknown and fatal error. cpia re q uires up to 3 independent power supplies. when cpia is desi g ned into a product providin g full usb power consumption compliance, the s y stem must provide cpia with vdd=5v, a switched vdda=5v and vddu=3.3v ( for internal usb differential pads ) . if cpia is used in a tar g et application where onl y the parallel port interface is re q uired and sli g htl y hi g her module power consumption is permitted, a sin g le, constant 5v suppl y can be safel y fed to vdd, vdda and vddu. vdd and vddu must alwa y s be permanentl y connected to s y stem power supplies. the switched vdda power line is t y picall y supplied usin g a power fet external to cpia. the power mana g ement module provides two outputs for drivin g the fet g ates and hence is capable of enablin g or disablin g power to s y stem-level components; lopow and norm . lopow is asserted when cpia is read y for vdda to be powered and once power has been applied puts cpia into a state where commands received from the host pc can be processed. as well as vdda becomin g active, this also includes startin g up of hi g h-speed 14.318mhz and 48mhz clocks usin g external cr y stals, resettin g and initialisin g all internal state machines and lo g ic within vp, vc and cp modules. lopow is de- asserted at an y time the host pc re q uests the module is either put into a usb suspend condition or an y other host-application-dependent mode when ultra low power consumption is re q uired. norm is asserted when cpia is read y to put the module into the hi g hest power mode of operation which occurs when the camera becomes active and hi g h speed ima g e transfers via usb or parallel port interfaces commences. norm is used internall y to cpia onl y but is provided as an optional output for drivin g customer- specific lo g ic. for example, norm can be used to illuminate an led indicatin g the camera is active. norm is also deasserted at an y time the host re q uests usb suspend mode. vp video data interface power management cp control interface usb parallel port interface d+ streamer data compression image dram controller d- registers block dia g ram of cpia video compressor module clk400h reset lowpo norm rama[8:0] ramd[15:0] lcas ucas ras we
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 11 colour processor interface asic commercial in confidence cpias power mana g ement block re q uires two externall y derived inputs: reset provides a g lobal reset to all cpia lo g ic and clk400h provides a low fre q uenc y clock to cpias internal power control state machines and should be constrained in accordance with the timin g dia g rams presented below. the events are also described in the table below. after event rr, the process returns to csu. effect of lopow on cpia-based module power consuption with external control of vdda using external fet. norm is shown for reference only and is not required for power control using external fet. lopow norm mode description vdda approx module current 1 1 suspend cpia, camera module and dram components are in lowest power mode. vdda is withdrawn as external fet is off, all fast clocks are disabled and cpia logic is in held reset 0v <500ua 0 1 low power cpia is in low power mode. fast clocks enabled and cpia can process commands from host pc. camera, video processing and dram controller modules are held in reset 5v <50ma 0 0 high power all cpia modules, camera and dram components are active and video data is being transferred to host pc. 5v <250ma if vdda is not controlled using vdda (vdd=vdda=vddu) in parallel port modes of operation, approx module power consumption will be <250ma at all times. in such cases, lopow and norm can be considered redundant. reset clk400h lowpo cki14 cki48 norm sclk vdda event por csu lpm rhp hpi hpm sr susp rr csu tp trp trl tck1su tck2su trvda tllp timin g dia g ram hi g hli g htin g power mana g ement events tnsclk tnhpm trhp ts r s trrc
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 12 colour processor interface asic commercial in confidence event description por power on reset provided to cpia by external hardware csu high frequency clock start up lpm low power mode of cpia operation rhp host request for cpia to enter high power state hpi initialise high power mode of operation hpm high power mode of cpia operation sr usb request power saving suspend mode of operation susp cpia held in usb suspend mode rr usb request resume to recover low power mode of operation parameter description min max units trp cpia global reset pulse width 0.1 - ms tp cpia clk400h period 2.25 2.75 ms cpia clk400 duty 20:80 80:20 - trl time for low power mode after reset deasserted 0 tp ms tck1su 14.318mhz clock start-up time - tp ms tck2su 48mhz clock start-up time - (2*tp)-1 ms trvda vdda power supply rise time from lowpo asserted - tp ms tllp time from lowpo asserted to low power mode 2*tp ms tnsclk time from norm to camera interface active ms tnhpm time from norm to high power mode ms trhp time to acknowledge host request for high power mode ms tsrs time for cpia to acknowledge and act upon usb suspend mode request ms trrc time for cpia to acknowledge and act upon usb resume low power mode request ms
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 13 colour processor interface asic commercial in confidence 2.2.2 video compression in the discussion to follow the cpia device is assumed to be interfaced to the the host pc via the usb, however the discussion e q uall y well applies to the parallel port interface option that cpia also provides. the vp module provides the video data stream to vc. the pixel-based compression al g orithm operates b y considerin g the differences between consecutive frames and encodin g those differences in a run-len g th buffer ( rlb ) held in external dram. the result is a run-len g th encoded stream of the chan g es from frame-to- frame. the stream consists of run-len g ths of re g ions where no chan g e has occurred, coded ycbycr ( yuv422 ) values of pixel-pairs which have chan g ed si g nificantl y , additional codes to mark the start/end/len g th of frame rows, a frame header detailin g parameters associated with the capture settin g s of the encoded data and finall y codes to mark the end of the encoded frame. the vc module implements the compression al g orithm conceptuall y b y wa y of two processes. the first process is the differencin g en g ine/run-len g th encoder ( de/rle ) : ? each pixel-pair of the current video frame is compared in turn with the correspondin g pixel-pair stored in the dram framestore ( fs ) . if this comparison indicates that there exists a si g nificant difference in value for the g iven pixel-pair then that pixel-pairs value is stored at the next locationin the rlb .the stored value is further coded to indicate its status as a pixel-pair value rather than a run-len g th . conversel y , if the comparison indicates that the difference is not si g nificant, a run-len g th counter is incremented and stored at the current position in the rlb. the level of significant difference is d y namicall y calculated b y the cp module from frame-to-frame and can be influenced b y the host pc. when the de/rlb finishes processin g a frame the cp module is alerted indicatin g subse q uent processes can commence. the second process is the data streamer/run-len g th decoder ( ds/rld ) : ? in parallel with the de/rle but dela y ed with respect to the current position in the rlb, the data streamer ( ds ) streams data from the rlb to usb interface module for transfer to the host. in addition, the ds also decodes the rlb stream back into the fs thus updatin g it. the software driver also decodes the received rlb stream on the host pc. when the ds/rlb reaches the end of the data stream the cp module is a g ain alerted and the process repeats. it is important to note that the two processes can run concurrentl y , that is the de/rle can be encodin g the current frame into the rlb while at the same time the de/rle can be streamin g out the previousl y encoded frame to the usb. framestore external dram encode decode cp module video compression difference engine & run length encoder run-len g th buffer host pc video compression components and vc module interfacin g to external dram usb/pp interface data streamer run length encoder cpia modules vp video data interface
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 14 colour processor interface asic commercial in confidence 2.2.3 dram interface in order to perform video capture and compression, cpia depends upon an a frame store provided b y a sin g le, low cost dram. the inte g ral dram controller is desi g ned to support standard 256k x 16 edo devices, with access times better than or e q ual to 60ns. timin g dia g rams showin g bus read and write c y cles are hi g hli g hted below. as seen in section 2.2.2, the compression al g orithm uses two main data structures within the dram: ? the framestore holds a cop y of the previous ima g e uploaded to the host. the de uses this information to determine si g nificant differences between the fs ima g e and the next ima g e read from the vp. ? the run len g th buffer stores the current frame in a run-len g th encoded form, read y for upload b y the ds/ usb to the host. ramd[15:0] ramlcas_n ramucas_n ramwe_n ramras_n rama[8:0] t asr t rc t ras, t rasp t rp t crp t ar t ach row col col row col t cah t asc t rah t rsh t rrh, t rch t cas, t clch t aa t rac data valid xx xx xx xx t cpa t off t cac t clz t rcd t csh t rcs t chr dram read c y cle timin g ramd[15:0] ramlcas_n ramucas_n ramwe_n ramras_n rama[8:0] dram write c y cle timin g t rasp t rsh t rp t rwl t csh t crp t rcd t cas t clch t pc t cp row col row col data valid t cah t asc t ach t ar t rah t asr t cwl t wcs t wp t wcr t ds t dh
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 15 colour processor interface asic commercial in confidence note 1 - dram timing parameters extracted from dram manufacturer s -6 worst-case spec data tables. due to some variation in ma nufacturers figures it is recommended required values presented in this table are closely checked against the data tables from specific target dram ma nufacturers. note 2 - min and max timing derived from worst and best case design simulation wih respect to process parameter derating with s upply voltage and tj. all timing parameters listed have been verified and validated through device characterisation with ta@25c, vdd=vdda=5v. cpia dram interface timing parameters parameter dram requirement (ns) note 1 cpia dram timing (ns) note 2 parameter dram requirement (ns) note 1 cpia dram timing (ns) note 2 min max min max t aa >30 43 58 t cas >10 28 40 t ach >15 52 58 t cah >10 28 40 t ar >45 68 72 t chr >10 28 40 t asc >0 17 21 t clch >10 28 40 t asr >0 68 72 t clz 0 0 0 t cac >17 19 26 t cp >8 28 40 t crp >5 68 72 t cpa >35 62 65 t csr >5 28 40 t csh >45 68 72 t dh >10 28 40 t cwl >10 52 57 t ds >0 28 40 t off 060 63 67 t pc >25 68 72 t ras >60 68 72 t rah >10 11 21 t rrh >0 68 72 t rasp >60 68 72 t rcd 14105 136 144 t rcs >0 28 40 t rch >0 68 72 t rp >40 68 72 t ref <8ms - 16us t rwl >15 52 57 t rpc >5 28 40 t wch >10 28 40 t t <2 0.5 2 t wcs >0 17 20 t wcr >45 68 72 t wp >5 52 57 t rsh >15 28 40 framestore and run length buffer dram partitioning data structure size ( b y tes ) size ( kb y tes ) framestore ( fs ) 202752 198 run-len g th buffer ( rlb ) 205124 ~201 total ( fs + rlb ) 407876 ~399
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 16 colour processor interface asic commercial in confidence 2.2.4 usb interface the usb interface is full y compliant with usb specification version 1.0. the usb interface is desi g ned such that the camera attaches to the pc via a 4-wire usb cable, either directl y at the pc motherboard usb connector ( root hub ) or via a usb hub ( in turn connected to the pc motherboard root hub ) . the usb hub ma y be either a stand-alone usb hub device or a compound usb hub device incorporated, for example, in a usb monitor or printer. usb transfers both si g nal and power over the 4-wire cable such that the camera is powered from the same cable/connector over which it communicates with the pc. the 4-wire cable carries vbus ( nominall y +5v at the source ) and gnd wires to deliver power to devices and differential data lines, d+ and d-. the clock is transmitted encoded alon g with the differential data. the clock encodin g scheme is nrzi with bit stuffin g to ensure ade q uate transitions. a sync field precedes each packet to allow the receiver ( s ) to s y nchronise their bit recover y clocks. cpia provides full y compliant usb differential pads on-chip so there is no need to use an external, discrete bus tranceiver chip such as philips pdiusbp11. in accordance with the usb specification version 1.0, the pads have been characterised for correct operation up to the maximum peripheral cable len g th of 5m. 2.2.4.1 cpia-based usb camera the cpia-based usb camera is a hi g h-power, bus-powered device. when it is first attached to a usb hub port it operates in its low-power mode consumin g no more than 100ma. once the camera has been successfull y enumerated it ma y operate in its hi g h-power mode in which it consumes no more than 400ma. since the camera is a hi g h-power, bus-powered device it will onl y enumerate successfull y if connected to a self-powered usb hub. ( a bus-powered usb hub is onl y capable of suppl y in g 100ma at each of its downstream ports ) . the cpia-based usb camera responds to suspend si g nallin g issued b y the usb ( more than 3ms of bus idle time ) . in its suspend mode of operation the camera draws no more than 500ua. the camera does not support remote wakeup. the cpia usb camera is a sin g le confi g uration, sin g le interface usb peripheral device. its sin g le interface ( interface 1 ) supports control endpoint 0 and isochronous in endpoint 1. all devices must support control endpoint 0 as this is the endpoint with which the pc communicates over the default pipe at device enumeration time. cpia utilises control endpoint 0 to respond to standard usb commands ( such as those used at device enumeration time ) and to vendor specific cpia commands which are used to control the operation of the camera and to re q uest status information from the camera. note that the camera does not support a usb class specification and so onl y vendor commands are used to control the operation of the camera. isochronous in endpoint 1 is used to transfer video data from the camera to the pc. usin g an isochronous endpoint for this task g uarantees bandwidth and latenc y for the transfer of video data. the bandwidth re q uested for video data transfer can be varied b y means of the four defined alternate settin g s of interface 1. 2.2.4.2 usb control transfers control transfers are used to pass control information to the cpia-based usb camera from the host and to re q uest state information back from the camera. for example, control transfers are used at device enumeration time when the host pc re q uests information about the usb device which has been d y namicall y attached to the bus to enable it to load the appropriate driver ( s ) . ( usb device enumeration is discussed in detail in section 2.2.4.3 ) . cpia uses control endpoint 0 for all control transfers. therefore endpoint 0 handles both standard usb commands and vendor specific cpia commands. a control transfer consists of three phases: a setup phase, a data phase ( should one exist ) and a status phase.
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 17 colour processor interface asic commercial in confidence the setup phase contains details of the command bein g sent to the camera includin g , the specific command re q uest, whether the command is a write ( host to camera ) or read ( camera to host ) command and the number of b y tes expected in the data phase. ( for further information on the setup phase please refer to usb specification version 1.0, section 9.3 ) . the data phase is used to transfer a number of b y tes of information associated with the command to the camera if this is a write command or from the camera if this is a read command. the data phase can consist of a number of discrete data transactions on the bus. with cpia-based usb cameras, data is transfered in 8-b y te packets with the remainin g data b y tes transfered in the last data transaction bein g less than 8 b y tes if the total number of b y tes to be transfered is not a multiple of 8. this is because the maximum packet size of control endpoint 0 in cpia is 8 b y tes. the status phase is used to indicate whether or not all was well with the setup and data phases and conse q uentl y whether or not the control transfer has completed successfull y . if at an y time the camera receives an unreco g nised command ( for example due to data corruption on the usb ) or it cannot process a valid command for some reason it returns a stall handshake on the bus to indicate to the host that somethin g is wron g . 2.2.4.3 usb device enumeration the usb hub detects that a hi g h speed usb device has been d y namicall y attached to one of its downstream ports b y the presence of a 1.5kohm pull-up resistor on the d+ differential data line on the upstream port of the device, as is the case with a cpia-based usb camera. before the port to which the camera has been connected can be enabled the hub ensures that the device is reset. it does this b y issuin g se0 reset si g nallin g on the usb differential data lines for at least 10ms and then enables the port. this causes the camera to listen to usb traffic at bus address 0 until such time as it is assi g ned its own uni q ue usb bus address. the camera is read y to respond to host access within 10ms of this reset si g nallin g bein g de- asserted. note that the hub waits a specified dela y time after device attach before issuin g the reset si g nallin g to ensure the devices internal power suppl y has stabilised. now that the camera is listenin g at bus address 0 the host be g ins to communicate with the camera. the initial communications comprise the device enumeration traffic se q uence. the host first issues a getdescriptor ( device ) command ( setup packet 80 06 00 01 00 00 40 00) to control endpoint 0 ( which all usb devices must support ) at bus address 0. the host onl y receives the first 8 data b y tes of the data phase of this control transfer ( that is, the first data transaction within the data phase ) before issuin g the status phase. the host then issues a setaddress command ( setup packet 00 05 yz wx 00 00 00 00 where wx y z is the usb device address ) to assi g n a uni q ue usb bus address to the camera. followin g the status phase of a successful setaddress command the camera then listens and responds to usb traffic at this uni q ue address onl y . the host continues b y issuin g a getdescriptor ( device ) command ( setup packet 80 06 00 01 00 00 12 00 ) . in response to the getdescriptor ( device ) command the camera returns its device descriptor which comprises 18 bytes of information. the device descriptor describes general information about the usb device. the table below shows the device descriptor information returned by a cpia-based usb camera in response to the getdescriptor (device) command. this information can be checked at device enumeration time using a usb bus analyser such as the catc inspector when debugging a cpia-based usb camera design. descriptor field size (bytes) value description blength 1 0x12 size of this descriptor in bytes. bdescriptortype 1 0x01 device descriptor type.
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 18 colour processor interface asic commercial in confidence notes: ( 1 ) the cpia device returns a product id as part of its device descriptor. this product id is used alon g with the vendor id to load the approriate device drivers for the cpia-based usb camera. the device can return two possible product id numbers dependin g on the state of the id_select pin. this pin has an internal pull- up resistor which, when not connected, provides a product id of 0x0002 for a usb-onl y cpia-based camera module. when the id_select pin is pulled low externall y , the product id will be 0x0001, which is used for a combined parallel port and usb module. ( 2 ) the usb camera does not support strin g descriptors. any request by the host for a string descriptor will cause the camera to stall the default pipe. finall y the host issues a getdescriptor ( configuration ) command ( setup packet 80 06 xx 02 00 00 ff 00 ) . cpia has only one configuration (index xx = 00). if xx is anything other than 00 cpia will stall the default pipe. in response to the getdescriptor ( configuration ) command the camera returns its configuration, interface and endpoint descriptors which comprise 73 bytes of information. the tables below show the descriptor information returned by a cpia-based usb camera in response to the getdescriptor (configuration) command. this information can be checked at device enumeration time using a usb bus analyser such as the catc inspector when debugging a cpia-based usb camera design. bcdusb 2 0x0100 usb specification release number identifying the release of the usb specification that the device and its descriptors are compliant with. (release 1.00) bdeviceclass 1 0x00 class code (assigned by usb). this field is set to 0x00 meaning that the class information is specified in the interface descriptor. bdevicesubclass 1 0x00 subclass code (assigned by usb). bdeviceprotocol 1 0x00 protocol code (assigned by usb). this field is set to 0x00, meaning that the device does not use class spe- cific protocols on a device basis, however may use class specific protocols on an interface basis. bmaxpacketsize0 1 0x08 maximum packet size for endpoint 0. idvendor 2 0x0553 vendor id (assigned by usb). idproduct 2 0x0002 (1) product id (assigned by the manufacturer). bcddevice 2 0x0100 device release number in binary-coded decimal. imanufacturer 10x00 (2) index of string descriptor describing manufacturer. iproduct 10x00 (2) index of string descriptor describing product. iserialnumber 10x00 (2) index of string descriptor describing the devices serial number. bnumconfigurations 1 0x01 number of possible configurations descriptor field size (bytes) value description blength 1 0x09 size of this descriptor in bytes. bdescriptortype 1 0x02 configuration descriptor type. descriptor field size (bytes) value description
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 19 colour processor interface asic commercial in confidence wtotallength 2 0x0049 total length of data returned for this configuration. includes the combined length of all descriptors (config- uration, interface, endpoint, and class or vendor spe- cific) returned for this configuration. bnuminterfaces 1 0x01 number of interfaces supported by this configuration. bconfigurationvalue 1 0x01 value to use as an argument to setconfiguration to select this configuration. iconfiguration 10x00 (1) index of string descriptor describing this configuration. bmattributes 1 0x80 configuration characteristics: bus powered and no remote wakeup. maxpower 1 0xc8 maximum power consumption of usb device from the bus in this specific configuration when the device is fully operational. expressed in 2ma units ( 0xc8 = 400ma). descriptor field size (bytes) value description blength 1 0x09 size of this descriptor in bytes. bdescriptortype 1 0x04 interface descriptor type. binterfacenumber 1 0x01 number of interface. balternatesetting 1 0x00 value used to select alternate setting for the interface identified in the prior field. bnumendpoints 1 0x01 number of endpoints used by this interface (excluding endpoint 0). binterfaceclass 1 0xff class code (assigned by usb). a value of 0xff means that the interface class is vendor specific. binterfacesubclass 1 0x00 subclass code (assigned by usb). binterfaceprotocol 1 0xff protocol code (assigned by usb). a value of 0xff means that the device uses a vendor specific protocol for this interface. iinterface 10x00 (1) index of string descriptor describing this interface. descriptor field size (bytes) value description blength 1 0x07 size of this descriptor in bytes. bdescriptortype 1 0x05 endpoint descriptor type. descriptor field size (bytes) value description
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 20 colour processor interface asic commercial in confidence bendpointaddress 1 0x81 the address of the endpoint on the usb device described by this descriptor: (in endpoint, number 1) bmattributes 1 0x01 field describing the endpoints attributes: isochronous transfer type. wmaxpacketsize 2 0x0000/ 0x0000 (2) maximum packet size this endpoint is capable of send- ing: 0 bytes or 0 bytes (2) . binterval 1 0x01 interval for polling endpoint for data transfers (in ms). for isochronous endpoints this field must be set to 1 (ie. every usb frame). descriptor field size (bytes) value description blength 1 0x09 size of this descriptor in bytes. bdescriptortype 1 0x04 interface descriptor type. binterfacenumber 1 0x01 number of interface. balternatesetting 1 0x01 value used to select alternate setting for the interface identified in the prior field. bnumendpoints 1 0x01 number of endpoints used by this interface (excluding endpoint 0). binterfaceclass 1 0xff class code (assigned by usb). a value of 0xff means that the interface class is vendor specific. binterfacesubclass 1 0x00 subclass code (assigned by usb). binterfaceprotocol 1 0xff protocol code (assigned by usb). a value of 0xff means that the device uses a vendor specific protocol for this interface. iinterface 10x00 (1) index of string descriptor describing this interface. descriptor field size (bytes) value description blength 1 0x07 size of this descriptor in bytes. bdescriptortype 1 0x05 endpoint descriptor type. bendpointaddress 1 0x81 the address of the endpoint on the usb device described by this descriptor: (in endpoint, number 1) bmattributes 1 0x01 field describing the endpoints attributes: isochronous transfer type. descriptor field size (bytes) value description
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 21 colour processor interface asic commercial in confidence wmaxpacketsize 20x01c0/ 0x0140 (2) maximum packet size this endpoint is capable of send- ing: 448 bytes or 320 bytes (2) . binterval 1 0x01 interval for polling endpoint for data transfers (in ms). for isochronous endpoints this field must be set to 1 (ie. every usb frame). descriptor field size (bytes) value description blength 1 0x09 size of this descriptor in bytes. bdescriptortype 1 0x04 interface descriptor type. binterfacenumber 1 0x01 number of interface. balternatesetting 1 0x02 value used to select alternate setting for the interface identified in the prior field. bnumendpoints 1 0x01 number of endpoints used by this interface (excluding endpoint 0). binterfaceclass 1 0xff class code (assigned by usb). a value of 0xff means that the interface class is vendor specific. binterfacesubclass 1 0x00 subclass code (assigned by usb). binterfaceprotocol 1 0xff protocol code (assigned by usb). a value of 0xff means that the device uses a vendor specific protocol for this interface. iinterface 10x00 (1) index of string descriptor describing this interface. descriptor field size (bytes) value description blength 1 0x07 size of this descriptor in bytes. bdescriptortype 1 0x05 endpoint descriptor type. bendpointaddress 1 0x81 the address of the endpoint on the usb device described by this descriptor: (in endpoint, number 1) bmattributes 1 0x01 field describing the endpoints attributes: isochronous transfer type. wmaxpacketsize 20x02c0/ 0x0268 (2) maximum packet size this endpoint is capable of send- ing: 704 bytes or 616 bytes (2) . binterval 1 0x01 interval for polling endpoint for data transfers (in ms). for isochronous endpoints this field must be set to 1 (ie. every usb frame). descriptor field size (bytes) value description
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 22 colour processor interface asic commercial in confidence notes: ( 1 ) the usb camera does not support strin g descriptors. any request by the host for a string descriptor will cause the camera to stall the default pipe. ( 2 ) the first number shows maximum packet size values returned when usb_bandwidth is left unconnected ( internall y pulled up ) , as is the case in normal operation. if usb_bandwidth is pulled lo externall y the second number is returned as the maximum packet size for the isochronous endpoint. for further information see section 2.2.4.4 . on successful completion of these control transfers the host has g athered all relevant information about the descriptor field size (bytes) value description blength 1 0x09 size of this descriptor in bytes. bdescriptortype 1 0x04 interface descriptor type. binterfacenumber 1 0x01 number of interface. balternatesetting 1 0x03 value used to select alternate setting for the interface identified in the prior field. bnumendpoints 1 0x01 number of endpoints used by this interface (excluding endpoint 0). binterfaceclass 1 0xff class code (assigned by usb). a value of 0xff means that the interface class is vendor specific. binterfacesubclass 1 0x00 subclass code (assigned by usb). binterfaceprotocol 1 0xff protocol code (assigned by usb). a value of 0xff means that the device uses a vendor specific protocol for this interface. iinterface 10x00 (1) index of string descriptor describing this interface. descriptor field size (bytes) value description blength 1 0x07 size of this descriptor in bytes. bdescriptortype 1 0x05 endpoint descriptor type. bendpointaddress 1 0x81 the address of the endpoint on the usb device described by this descriptor: (in endpoint, number 1) bmattributes 1 0x01 field describing the endpoints attributes: isochronous transfer type. wmaxpacketsize 20x03c0/ 0x0380 (2) maximum packet size this endpoint is capable of send- ing: 960 bytes or 896 bytes (2) . binterval 1 0x01 interval for polling endpoint for data transfers (in ms). for isochronous endpoints this field must be set to 1 (ie. every usb frame).
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 23 colour processor interface asic commercial in confidence camera and is able to load the appropriate drivers for the camera. once this has been done the camera is said to be enumerated. 2.2.4.4 usb isochronous transfers as stated in section 2.2.4.1 , isochronous in endpoint 1 is used to transfer video data from the camera to the host. interface 1 has four alternate settin g s defined allowin g different usb bandwidths to be re q uested for this transfer of video data. furthermore, it is possible to use the usb_bandwidth input to select a second set of alternate settin g isochronous bandwidths. in normal operation usb_bandwidth is left unconnected ( internall y pulled up ) . if it is pulled lo externall y a second set of alternate settin g isochronous bandwidths are used. the table below shows the alternate settin g isochronous bandwidths of endpoint 1 for both usb_bandwidth hi and lo. note that the second set of alternate settin g bandwidths available b y pullin g usb_bandwidth lo allow a sli g htl y lower set of bandwidth settin g s to be used. the isochronous bandwidth is reported as the number of b y tes per usb frame. the usb is framed into 1ms time slots. alternate settin g 0 is alwa y s 0 b y tes/ms. this ensures that we can select an alternate settin g for the camera where no bandwidth is reserved. alternate settin g 0 is the default alternate settin g selected when the cpia usb driver is loaded, such that when the camera is enumerated but not in operation ( no application is usin g the camera hardware to transfer video data ) then no usb bandwidth is re q uested. this is essential for a usb- friendl y peripheral such that other devices ma y use the full potential of the bus at this time. when an application wishes to use the camera the cpia usb driver will re q uest isochronous bandwidth for the transfer of video data. it will start b y re q uestin g the lar g est bandwidth supported b y cpia, that is alternate settin g 3, to ensure the best possible framerate b y default. if the usb bus has man y isochronous devices attached and alternate settin g 3 cannot be supported the cpia usb driver will then re q uest alternate settin g 2 and if necessar y alternate settin g 1 to g uarantee bandwidth for the transfer of video data. if even the bandwidth re q uirement of alternate settin g 1 cannot be supported b y the bus at that time the user will have to stop usin g another isochronous device to free-up isochronous bus time to allow the usb camera to operate. additionall y , the camera user can select the usb bandwidth the y wish to use b y means of the multimedia control panel settin g s dialo g ue for the camera. here the y can select hi g h ( alternate settin g 3 ) , medium ( alternate settin g 2 ) or low ( alternate settin g 1 ) usb bandwidth. thus if the cpia camera is currentl y usin g hi g h bandwidth and the y wish to connect and simultaneousl y use another isochronous usb device the y can manuall y force the cpia camera to use less bandwidth b y selectin g medium or low bandwidth settin g s. obviousl y this ma y result in lower framerate video ( dependin g on the current compression settin g) . once an alternate settin g has been selected and is supported b y the bus then the cpia camera has g uaranteed bandwidth and latenc y for the transfer of video data. this means that in ever y 1ms usb time slot an in token will be issued to the cpia endpoint 1 for the transfer of up to maxpacketsize b y tes of video data, where maxpacketsize is the reserved bandwidth per ms. the cpia camera will transfer as much data as it currentl y has available up to maxpacketsize . when no compression is selected then maxpacketsize b y tes of video data will be transfered in ever y usb frame. if compression is selected then less than maxpacketsize b y tes of video data ma y be transfered dependin g on the level of compression re q uested. when the device is alternate setting isochronous bandwidth per ms usb_bandwidth=1 (default) isochronous bandwidth per ms usb_bandwidth=0 00 b y tes 0 b y tes 1 448 b y tes 320 b y tes 2 704 b y tes 616 b y tes 3 960 b y tes 896 b y tes
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 24 colour processor interface asic commercial in confidence sendin g a compressed ima g e stream to the host the amount of data to be sent for each ima g e frame can var y , dependin g on the compression ratio achieved. to enable the host to detect the end of valid ima g e data the device inserts four 0xff values into the ima g e stream to mark the end of ima g e frame. as a se q uence of four 0xff values will never occur within a valid frame of ima g e data the host can use this to simpl y detect the end of the ima g e data, without havin g to decompress the ima g e. the host driver checks the inter g rit y of the ima g e data stream before it is decoded. if an y corruption is detected the frame is discarded and another uploaded.
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 25 colour processor interface asic commercial in confidence 2.2.5 parallel port interface the parallel port interface is desi g ned to attach directl y to the parallel printer port of a pc. as such it contains 8 bi-directional data lines, 4 control inputs and 5 status outputs for connection to the host parallel port. in addition, a further 4 outputs, 5 inputs are provided to support pass-throu g h parallel port desi g ns. these two ports are referred to as the host port and pass-through port. figure 2.5 : parallel port interface signals this followin g sections g ive a g uide to the low level protocols used to transfer command and ima g e data over the parallel port interface. the y should be read in con j unction with the document "ieee std 1284 - standard si g nalin g method for a bidirectional parallel peripheral interface for personal computers". it is intended to g ive users enou g h information to desi g n and debu g boards utilisin g the cpia device. 2.2.5.6 parallel port protocol there are three classes of transfer that take place over the parallel port. ? ieee std 1284 device id transfers ? command / status transfers ?ima g e stream transfers 1284 device id transfers are used b y the microsoft windows 95/98 operatin g s y stems to detect the presence of the cpia-based camera at boot time and load the approriate drivers. command and status transfers are used to pass control information to the cpia-based camera from the host as well as returnin g state information back to the host. ima g e stream transfers are used to transfer ima g e data from cpia to the host. this data can be in a compressed or uncompressed format dependin g on how the cpia has been set up via the associated host pc software driver. host pc parallel port pass- through port control control status status data cpia device data h_strobe h_autofd h_init h_selectin h_fault h_ack h_busy h_perror h_select hp_data0:7 p_strobe p_autofd p_init p_selectin p_fault p_ack p_busy p_perror p_select
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 26 colour processor interface asic commercial in confidence 2.2.5.7 1284 device id transfers the cpia device can return a device id strin g , as defined in ieee std 1284, usin g nibble mode reverse channel transfer. this device id is re q uested b y the microsoft windows 95/98 operatin g s y stems durin g their pnp boot processes. it is used to load the approriate device drivers for the hardware attached to the port. the device can return two possible device id strin g s dependent on the state of the id_select pin. this pin has an internal pull-up resistor which, when not connected, provides a device id for a parallel port onl y cpia- based camera module. when pulled low externall y , the device id will be that which is used for a combined parallel port and usb module. the complete device ids returned in these two situations are shown in the table below. 2.2.5.8 command / status transfers all command and status transfers are preceeded b y the ne g otiation and setup phases as defined in the std 1284 for the ecp and nibble modes. forward data transfers alwa y s use the ecp transfer protocol. reverse data transfers use either ecp, or nibble mode, transfer protocols, dependin g or whether the host has a bi-directional port or not. channel addressin g and rle as defined in the ecp spec are not used b y cpia. data is transfered in 8 b y te packets, each packet bein g preceeded b y the 1284 ne g otiation and setup se q uences, and terminated with a 1284 termination se q uence. commands are passed to cpia in a sin g le 8 b y te packet, termed a command transfer. this can optionall y be followed b y the transfer of a d ata transfer. b y tes within the command packet are used to specif y whether a data packet is to follow, and its direction. most commands are not accompanied b y data packets. the followin g dia g ram, fi g ure x.y, shows the activit y that occurs on the parallel port control and status lines durin g a command transfer to cpia, via a forward ecp mode transfer. note - the actual data is carried on the 8 data lines, which are not shown on the dia g ram. id_select returned device id 1 ( default ) mfg:vlsi vision ltd;mdl:ppc2 camera;cmd:cpia_1-20;cls:media;des:parallel port camera; 0 mfg:vlsi vision ltd;mdl:dual-b camera;cmd:cpia_1-20;cls:media;des:usb / parallel port camera;
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 27 colour processor interface asic commercial in confidence figure 2.9 : typical forward ecp command transfer to cpia the dia g ram below, fi g ure x.y, shows the activit y that occurs on parallel port control and status lines durin g the return of status information to the host via a nibble mode transfer. in this transfer mode the actual data is carried on the perror, nautofd, nack, select lines. figure 2.10 : reverse nibble status transfer to host 50 s div 100 s div
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 28 colour processor interface asic commercial in confidence the dia g ram below, fi g ure x.y, shows the activit y that occurs on parallel port control and status lines durin g the return of status information to the host via a reverse ecp mode transfer. note - the actual data is carried on the 8 data lines, which are not shown on the dia g ram. figure 2.11 : typical reverse ecp status transfer to host 50 s div
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 29 colour processor interface asic commercial in confidence 2.2.5.12 image stream transfers transfers of ima g e stream data are distin g uished from those of the command and status data b y the use of a sli g htl y different ne g otiation phase preceedin g the transfer. ima g e stream transfers operates onl y in the reverse direction i.e. cpia to host. all ima g e stream transfers are preceeded b y a 1284 ne g otiation se q uence which sets the "extensiblit y link re q uest" bit within the first extensibilit y re q uest value. the subse q uent extensiblit y re q uest value then determines which of two possible transfer modes will be used to transfered the data. ima g e stream transfers are terminated with the standard 1284 termination se q uence. the protocol used to transfer the data depends on the capabilites of the host. if it has an ecp parallel port then the standard ecp b y te level protocol is used. however, if it has a bi-directional, or 4 bit port, then a modified form of the 1284 nibble mode transfer is used. this modified form, refered to hereafter as a nibble stream mode , is used in preference to the standard nibble mode to improve the maximum transfer rate. nibble stream mode differs from standard nibble mode b y the fact that both the risin g and fallin g ed g es of the nautofd si g nal are used to clock data. the dia g ram below shows the ne g otiation se q uence that proceeds a nibble stream mode transfer, and the start of of the actual ima g e data transfer. note - re q uests b y the host for nibble stream or ecp stream mode transfers can be easil y dis g uished from standard nibble mode and ecp ne g otiations b y the double nstrobe low pulses that occur durin g the ne g otiation phase. figure 2.13 : typical nibble stream negotiation 100 s div
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 30 colour processor interface asic commercial in confidence the dia g ram below shows the ne g otiation se q uence that proceeds a ecp stream mode transfer, no actual b y tes are shown bein g transfered. figure 2.14 : typical ecp stream negotiation notes on image stream transfers cpia produces a low g oin g pulse, of approximatel y 200 s , on the nack line when ima g e stream data is available to upload. if the host driver can use this pulse to tri gg er a parallel port interrupt service routine to start the the ima g e transfer process. when the device is sendin g compressed ima g e stream to the host the amount of data to be sent for each frame can var y , dependin g on the compression ratio achieved. so that the host can detect the end of valid data the device inserts a stream of 0xff values into the ima g e stream after the host reads past the end the valid ima g e data. as a se q uence of four 0xff values will never occur within a valid frame of ima g e data the host can use this to simpl y detect the end of the ima g e data, without havin g to decompress the ima g e. the host driver checks the inter g rit y of the ima g e data stream before it is decoded, if an y corruption is detected the frame is discarded and another uploaded. if, while uploadin g uncompressed ima g es, the transfer of data is monitored via an osciliscope, or lo g ic anal y ser, it will be seen there are re g ular short pauses in the transfer, in the order of 200 s to 2ms each. these are caused b y the host driver suspendin g the transfer while it copies data out of its temporar y buffer into the tar g et frame buffer. 50 s div
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 31 colour processor interface asic commercial in confidence details of nibble stream mode protocol the fi g ure below shows the details of the nibble stream protocol. it shows two succesive b y tes, a and b, bein g transfered. the host re q uests a b y te b y settin g nautofd to lo. cpia will then present the lower nibble of the b y te on the 4 status lines. it then sets nack lo to si g nif y that the data is read y . nautofd g oin g hi causes the upper nibble to be placed on the status lines and nack is then taken hi to si g nif y the data is read y for the host to read. figure 2.15 : nibble stream mode protocol 2.2.5.16 pass-through mode ? the cpia device includes support for a parallel port pass-throu g h mode of operation to allow another parallel port device, e. g . a printer, to be dais y chained from a cpia-based camera. ? the windows 95/98 device driver supplied b y vlsi vision ltd does not y et support his feature and so onl y a brief description of the operation of this mode will be g iven here. ? please contact vision for more information. description of pass-through mode operation the host can instruct the cpia to enter pass-throu g h mode b y sendin g it a gotopassthrough command. all host control si g nals will then be echoed to the pass-throu g h port and status si g nals from the pass-throu g h port will be echoed back to the host. in this mode the host has unrestricted access the pass-throu g h device and ma y use it as if the cpia-based camera was not attached. while in this mode the cpia will not attempt to initiate communications with the host, or in an y wa y interfere with the host to pass-throu g h device communication that ma y be takin g place. when the host re q uires to communicate with cpia, it must switch cpia out of pass-throu g h mode b y sendin g it a vpp ( vision passthrou g h packet ) , which has a similar structure and si g nalin g method as that defined in the ieee 1284.3 draft specification. this vpp packet is sent usin g onl y the 8 data lines without an y strobin g or acknowled g in g on the control or status lines, this ensures that the pass-throu g h device will not respond to it. nack nautofd data bit a:0 data bit b:0 data bit a:4 nfault data bit a:3 data bit b:3 data bit a:7 busy data bit a:2 data bit b:2 data bit a:6 perror data bit a:1 data bit b:1 data bit a:5 select data bit b:5 data bit b:4 data bit b:6 data bit b:7 p p p p p h
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 32 colour processor interface asic commercial in confidence when cpia switches from pass-throu g h into manual mode it locks the state of the pass-throu g h port control si g nals and prevents the pass-throu g h status si g nals from bein g echoed back to the host. the host can now communicate as it wishes with cpia without the pass-throu g h device bein g aware of an y activit y on the parallel port. 2.2.5.17 ieee 1284 mode handshake values the followin g table shows the timin g values of the parallel port interface in terms of the si g nal transitions defined in the ieee std 1284 fi g ures 3 throu g h 23. figure 2.18 : ieee 1284 mode handshake values notes: 1 - a dela y of more than this period durin g a command/status transfer can cause the watchdo g reset circuitr y on cpia to time out and g enerate a s y stem reset. 2 - normall y 10ms, however, certain commands bein g issued to cpia can caused this to increase to 40ms 3 - as an ecp forward channel stall condition will never be g enerated b y cpia, the host transfer recover y hand- shake is not supported. time minimum maximum description t h 0 0.5 s ( note 1 ) host response time t 0 infinite response time t l 70 ns 10 ms ( note 2 ) peripheral response time t r 70 ns peripheral response time ( ecp mode onl y ) t s ( note 3 ) host recover y time ( ecp mode onl y) t p 0.5 s minimum setup or pulse width t d 0 minimum data setup time ( ecp mode onl y)
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 33 colour processor interface asic commercial in confidence 2.2.6 control processor 2.2.6.19 control processor interfaces as shown in fi g ure 2.16 below, the control processor uses five main interfaces to control the operation of the cpia device: ? vp control re g isters ? vp frame start interrupt ? vc control re g isters i.e. pp, usb interfaces, compression control and dram interface ? usb_bandwidth , id_select and debug input pins ? uart serial comms ( debu g output onl y) figure 2.20 : control processor interfaces the vp control re g isters are used to control the colour processin g of the raw sensor data. colour channel g ains, colour saturation and contrast values are all applied b y the vp module. also, communications to the sensor, for control of exposure time and g ain, are done via the vp module. the vp frame start interrupt is used to tri gg er exposure control and auto white balance al g orithms that run on the control processor. the vc re g isters are used to control the host interfaces ( both parallel port and usb ) and the ima g e capture / compression / upload processes. in addition access to the dram, used to store the frameheader, and durin g self-test mode, is via the vc re g isiters. control of transitions between the s y stem power states of the camera is preformed via vc re g isters that access the power mana g ment module. the usb_bandwidth, id_select and debug inputs g o directl y to port pins on the embedded control processor core and modif y the several aspects of the camera behaviour. in normal operation these three inputs should be left unconnected ( internall y pulled up ) . the usb_bandwidth input can be used to select an alternate set of isochronous bandwidths for the usb interface. see the usb interface section of this document for more details. the id_select input is used to select a device id ( parallel port interface ) or product id ( usb interface ) that is used for combined usb and parallel port cameras. if held lo it causes a different 1284 device id to be returned on the parallel port interface, and a different usb product id on the usb interface. the debug input if pulled lo will cause the control processor to send dia g nostic output to the serial uart. control processor video proccessor parallel port interface usb interface image capture / compression dram interface serial uart usb_bandwidth id_select debug video compressor system dram frame start interrupt control processor
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 34 colour processor interface asic commercial in confidence this output consists mainl y of a trace of all command and status data that has been received/transmitted over the host parallel port or usb interfaces. the serial uart tx si g nal is used to output dia g nostic information. the rx input is not used to receive serial data, but the control processor does check its state after power up, or reset. if it is lo at this time the control processor enters a continuous self-test mode which it will remain in until the next s y stem reset. 2.2.6.21 control processor tasks the control processor is responsible for a variet y of functions necessar y for the operation of the cpia device. in brief these functions are: ? initialisation of vp and vc modules ? host communications via parallel port ieee 1284 protocol ? supervision of host usb interface ? host command execution ?ima g e capture / compression control ? camera auto exposure ? camera auto white balance ? production s y stem selftest dia g nostics ?dia g nostic debu g output 2.2.6.22 selftest diagnostics if the serial uart input rx is pulled lo when the s y stem is released from reset the control processor will enter self-test dia g nostics mode. it will continuousl y run a set of s y stem level tests and output the result on the serial uart tx output. the serial format used is 19200 baud, 8-bit data, no parit y , 1 stop bit, no flow control. below is t y pical output from the selftest mode. ====== cpia ver 1-20 ====== continuous selftest ... 1 - vp_en -------- 2 - vc_int -------- 3 - host port -------- 4 - pass-thru port fail 5 - usb core -------- 6 - vc register -------- 7 - dram access -------- 8 - vp register -------- 9 - frame grab -------- 10 - vp data -------- it should be noted that several of these self-tests where desi g ned to test s y stem level connectivit y between the vp, vc and cp modules durin g the device development phase, and are now effectivel y obseleted with the full inter g rated cpia device. these self-tests do not attempt to test in an y wa y the connectivit y , or correct operation, of the interface to the sensor. vp_en test tests an internal cpia control si g nal - should never fail. vc_int test tests an internal cpia control si g nal - should never fail. host port tests for short circuits between si g nals on the host parallel port. will fail if the camera is plu gg ed in a host.
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 35 colour processor interface asic commercial in confidence pass-thru port tests for short circuits and open circuits on the pass-throu g h parallel port. re q uires a special loop back connector to do the test, and so will fail if this is not present. usb core tests that the usb core has been succesfull y confi g ured. does not check actual communications with host. if the 48mhz xtal is fault y , or starts up too slowl y , this is test will fail. because of this parallel port onl y desi g ns will alwa y s show this test as failin g . vc register test tests internal cpia control si g nals - should never fail. dram access test checks for correct cpia access to dram. it does this b y writin g a test pattern to dram, and then verif y in g it. vp register test tests internal cpia control si g nals - should never fail. frame grab test tests internal cpia control si g nals - should never fail. vp data test puts vp module into colour bar mode, and captures a test ima g e to dram. then verif y s the correct data has been captured. if dram access test fails this test will also fail. 2.2.6.23 debug output if the debug input is pulled lo, the control processor will output dia g nostic information on the serial uart tx line. this output consists primaril y of a trace of all the command and status data transactions that occur over the host parallel port or usb interfaces. it was primaril y desi g ned to be of use for developers workin g on the host driver software. the serial format used is 19200 baud, 8-bit data, no parit y , 1 stop bit, no flow control. the followin g shows t y pical output followin g a s y stem reset and then subse q uent commands bein g received from the host b y the camera. ====== cpia ver 1-20 ====== process loop ... detected pp i/f command = 01 cmddata = 00 00 00 00 datain = 01 14 01 00 a2 88 88 85 command = 03 cmddata = 00 00 00 00 datain = 02 00 00 00 00 00 10 00 command = 04 cmddata = 00 00 00 00 command = a6 cmddata = 02 00 00 00 note - when the debu g output is enabled it si g nificantl y slows the handlin g of commands b y the camera, and thus the framerate acheived on the host will be much reduced.
v:\apps\cpia\docs\cpia datasheet\cpia_datasheet4.fm 02/07/98 36 colour processor interface asic commercial in confidence 3 mechanical information

▲Up To Search▲

Price & Availability of VV0670P001

	To Download VV0670P001 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .